SherbyNet - /page/wikibook/entry.mu

Micron Document

<!DOCTYPE html>

<title>Requirement</title>

</head>

<span id="openzim-page-title" class="mw-page-title-main"><span class="mw-page-title-main">Requirement</span></span>

</h1>

</header>

/* start https://en.wikipedia.org/ */

.mw-parser-output .hatnote{font-style:italic}.mw-parser-output div.hatnote{padding-left:1.6em;margin-bottom:0.5em}.mw-parser-output .hatnote i{font-style:normal}.mw-parser-output .hatnote+link+.hatnote{margin-top:-0.5em}@media print{body.ns-0 .mw-parser-output .hatnote{display:none!important}}

/* end https://en.wikipedia.org/ */

</style><div role="note" class="hatnote navigation-not-searchable">This article is about product and process development. For other kinds of requirements, see <a href="Need" title="Need">Need</a>, <a href="Obligation" title="Obligation">Obligation</a>, and <a href="Intelligence_requirement" title="Intelligence requirement">Intelligence requirement</a>. For historical usage, see <a href="Spanish_Requirement_of_1513" title="Spanish Requirement of 1513">Spanish Requirement of 1513</a>.</div>

<p>In <a href="Engineering" title="Engineering">engineering</a>, a <b>requirement</b> is a condition that must be satisfied for the output of a work effort to be acceptable. It is an explicit, objective, clear and often quantitative description of a condition to be satisfied by a material, design, product, or service.<sup id="cite_ref-1" class="reference"><a href="#cite_note-1"><span class="cite-bracket">[</span>1<span class="cite-bracket">]</span></a></sup>

</p><p>A <a href="Specification" class="mw-redirect" title="Specification">specification</a> or spec is a set of requirements that is typically used by developers in the design stage of <a href="New_product_development" title="New product development">product development</a> and by testers in their verification process.

</p><p>With <a href="Iterative_and_incremental_development" title="Iterative and incremental development">iterative and incremental development</a> such as <a href="Agile_software_development" title="Agile software development">agile software development</a>, requirements are developed in parallel with design and implementation. With the <a href="Waterfall_model" title="Waterfall model">waterfall model</a>, requirements are completed before design or implementation start.

</p><p>Requirements are used in many engineering fields including <a href="Engineering_design" class="mw-redirect" title="Engineering design">engineering design</a>, <a href="System_engineering" class="mw-redirect" title="System engineering">system engineering</a>, <a href="Software_engineering" title="Software engineering">software engineering</a>, <a href="Enterprise_engineering" title="Enterprise engineering">enterprise engineering</a>, <a href="New_product_development" title="New product development">product development</a>, and process optimization.

</p><p>Requirement is a relatively broad concept that can describe any necessary or desired function, attribute, capability, characteristic, or quality of a system for it to have value and utility to a customer, organization, user, or other stakeholder.

</p>

<div class="mw-heading mw-heading2"><h2 id="Origins_of_term">Origins of term</h2></div>

<p>The term <i>requirement</i> has been in use in the software engineering community since at least the 1960s.<sup id="cite_ref-2" class="reference"><a href="#cite_note-2"><span class="cite-bracket">[</span>2<span class="cite-bracket">]</span></a></sup>

</p><p>According to the <i>Guide to the Business Analysis Body of Knowledge®</i> version 2 from IIBA (BABOK),<sup id="cite_ref-3" class="reference"><a href="#cite_note-3"><span class="cite-bracket">[</span>3<span class="cite-bracket">]</span></a></sup> a requirement is:

</p>

<ol><li>A condition or capability needed by a stakeholder to solve a problem or achieve an objective.</li>

<li>A condition or capability that must be met or possessed by a solution or solution component to satisfy a contract, standard, specification, or other formally imposed documents.</li>

<li>A documented representation of a condition or capability as in (1) or (2).</li></ol>

<p>This definition is based on IEEE 610.12-1990: IEEE Standard Glossary of Software Engineering Terminology.<sup id="cite_ref-4" class="reference"><a href="#cite_note-4"><span class="cite-bracket">[</span>4<span class="cite-bracket">]</span></a></sup>

</p>

<div class="mw-heading mw-heading2"><h2 id="Product_versus_process_requirements">Product versus process requirements</h2></div>

<p>Requirements can be said to relate to two fields:

</p>

<ul><li><b>Product requirements</b> prescribe properties of a system or product.</li>

<li><b>Process requirements</b> prescribe activities to be performed by the developing organization. For instance, process requirements could specify the methodologies that must be followed, and constraints that the organization must obey.</li></ul>

<p>Product and process requirements are closely linked; a product requirement could be said to specify the automation required to support a process requirement while a process requirement could be said to specify the activities required to support a product requirement. For example, a maximum development cost requirement (a process requirement) may be imposed to help achieve a maximum sales price requirement (a product requirement); a requirement that the product be maintainable (a product requirement) often is addressed by imposing requirements to follow particular development styles (e.g., <a href="Object-oriented_programming" title="Object-oriented programming">object-oriented programming</a>), style-guides, or a review/inspection process (process requirements).

</p>

<div class="mw-heading mw-heading2"><h2 id="Types_of_requirements">Types of requirements</h2></div>

<p>Requirements are typically classified into types produced at different stages in a development progression, with the taxonomy depending on the overall model being used. For example, the following scheme was devised by the International Institute of Business Analysis in their Business Analysis Body of Knowledge<sup id="cite_ref-5" class="reference"><a href="#cite_note-5"><span class="cite-bracket">[</span>5<span class="cite-bracket">]</span></a></sup> (see also <a href="FURPS" title="FURPS">FURPS</a> and <a href="Requirements_analysis#Types_of_requirements" title="Requirements analysis">Types of requirements</a>).

</p>

<dl><dt><a href="System_architecture" class="mw-redirect" title="System architecture">Architectural requirements</a></dt>

<dd>Architectural requirements explain what has to be done by identifying the necessary integration of system <a href="Structure" title="Structure">structure</a> and system <a href="Behavior" title="Behavior">behavior</a>, i.e., <a href="System_architecture" class="mw-redirect" title="System architecture">system architecture</a> of a system.</dd>

<dd>In <a href="Software_engineering" title="Software engineering">software engineering</a>, they are called <a href="Architecturally_Significant_Requirements" class="mw-redirect" title="Architecturally Significant Requirements">architecturally significant requirements</a>, which is defined as those requirements that have a measurable impact on a software system’s <a href="Software_architecture" title="Software architecture">architecture</a>.<sup id="cite_ref-ASR_Chen_6-0" class="reference"><a href="#cite_note-ASR_Chen-6"><span class="cite-bracket">[</span>6<span class="cite-bracket">]</span></a></sup></dd></dl>

<dl><dt><a href="Business_requirements" title="Business requirements">Business requirements</a></dt>

<dd>High-level statements of the goals, objectives, or needs of an organization. They usually describe opportunities that an organization wants to realise or problems that they want to solve. Often stated in a <a href="Business_case" title="Business case">business case</a>.</dd></dl>

<dl><dt><a href="User_requirements_document" title="User requirements document">User (stakeholder) requirements</a></dt>

<dd>Mid-level statements of the needs of a particular stakeholder or group of stakeholders. They usually describe how someone wants to interact with the intended solution. Often acting as a mid-point between the high-level business requirements and more detailed solution requirements.</dd></dl>

<dl><dt><a href="Functional_requirements" class="mw-redirect" title="Functional requirements">Functional (solution) requirements</a></dt>

<dd>Usually detailed statements of capabilities, behavior, and information that the solution will need. Examples include formatting text, calculating a number, modulating a signal. They are also sometimes known as <i>capabilities</i>.</dd></dl>

<dl><dt><a href="Non-functional_requirements" class="mw-redirect" title="Non-functional requirements">Quality-of-service (non-functional) requirements</a></dt>

<dd>Usually detailed statements of the conditions under which the solution must remain effective, qualities that the solution must have, or constraints within which it must operate.<sup id="cite_ref-7" class="reference"><a href="#cite_note-7"><span class="cite-bracket">[</span>7<span class="cite-bracket">]</span></a></sup> Examples include: reliability, testability, maintainability, availability. They are also known as <i>characteristics</i>, <i>constraints</i> or the <i><a href="Ilities" class="mw-redirect" title="Ilities">ilities</a>.</i></dd></dl>

<dl><dt><a href="Implementation" title="Implementation">Implementation (transition) requirements</a></dt>

<dd>Usually, detailed statements of capabilities or behavior required only to enable the transition from the current state of the enterprise to the desired future state, but that will thereafter no longer be required. Examples include recruitment, role changes, education, migration of data from one system to another.</dd>

<dt><a href="Regulation" title="Regulation">Regulatory requirements</a></dt>

<dd>Requirements defined by <a href="Law" title="Law">laws</a> (Federal, State, Municipal, or Regional), <a href="Contract" title="Contract">contracts</a> (terms and conditions), or <a href="Policy" title="Policy"> policies</a> (company, departmental, or project-level).</dd></dl>

<div class="mw-heading mw-heading2"><h2 id="Characteristics_of_good_requirements">Characteristics of good requirements</h2></div>

<p>The characteristics of good requirements are variously stated by different writers, with each writer generally emphasizing the characteristics most appropriate to their general discussion or the specific technology domain being addressed. However, the following characteristics are generally acknowledged.<sup id="cite_ref-Davis93_8-0" class="reference"><a href="#cite_note-Davis93-8"><span class="cite-bracket">[</span>8<span class="cite-bracket">]</span></a></sup>

</p>

<th>Characteristic

</th>

<th>Explanation

</th></tr>

<tr>

<td>Unitary (Cohesive)

</td>

<td>The requirement addresses one and only one thing.

</td></tr>

<tr>

<td>Complete

</td>

<td>The requirement is fully stated in one place with no missing information.

</td></tr>

<tr>

<td><a href="Consistency" title="Consistency">Consistent</a>

</td>

<td>The requirement does not contradict any other requirement and is fully consistent with all authoritative external documentation.

</td></tr>

<tr>

<td>Non-Conjugated (<a href="Atomicity_(database_systems)" title="Atomicity (database systems)">Atomic</a>)

</td>

<td>The requirement is <i>atomic</i>, i.e., it does not contain conjunctions. E.g., "The postal code field must validate American <i>and</i> Canadian postal codes" should be written as two separate requirements: (1) "The postal code field must validate American postal codes" and (2) "The postal code field must validate Canadian postal codes".

</td></tr>

<tr>

<td><a href="Traceability" title="Traceability">Traceable</a>

</td>

<td>The requirement meets all or part of a business need as stated by stakeholders and authoritatively documented.

</td></tr>

<tr>

<td>Current

</td>

<td>The requirement has not been made obsolete by the passage of time.

</td></tr>

<tr>

<td><a href="Unambiguous" class="mw-redirect" title="Unambiguous">Unambiguous</a>

</td>

<td>The requirement is concisely stated without recourse to <a href="Technical_jargon" class="mw-redirect" title="Technical jargon">technical jargon</a>, <a href="Acronym" title="Acronym">acronyms</a> (unless defined elsewhere in the Requirements document), or other esoteric verbiage. It expresses objective facts, not subjective opinions. It is subject to one and only one interpretation. Vague subjects, adjectives, prepositions, verbs and subjective phrases are avoided. Negative statements and compound statements are avoided.

</td></tr>

<tr>

<td>Specify Importance

</td>

<td>Many requirements represent a stakeholder-defined characteristic the absence of which will result in a major or even fatal deficiency. Others represent features that may be implemented if time and budget permits. The requirement must specify a level of importance.

</td></tr>

<tr>

<td><a href="Verification_and_validation" title="Verification and validation">Verifiable</a>

</td>

<td>The implementation of the requirement can be determined through basic possible methods: inspection, demonstration, test (instrumented) or analysis (to include validated modeling & simulation).

</td></tr></tbody></table>

<p>There are many more attributes to consider that contribute to the quality of requirements. If requirements are subject to rules of <a href="Data_integrity" title="Data integrity">data integrity</a> (for example) then accuracy/correctness and validity/authorization are also worthy attributes. <a href="Traceability" title="Traceability">Traceability</a> confirms that the requirement set satisfies the need (no more - and no less than what is required).

</p><p>To the above some add Externally Observable, that is, the requirement specifies a characteristic of the product that is externally observable or experienced by the user. Such advocates argue that requirements that specify internal architecture, design, implementation, or testing decisions are probably constraints, and should be clearly articulated in the Constraints section of the Requirements document. The contrasting view is that this perspective fails on two points. First, the perspective does not recognize that the user experience may be supported by requirements not perceivable by the user. For example, a requirement to present <a href="Geocoding" class="mw-redirect" title="Geocoding">geocoded</a> information to the user may be supported by a requirement for an interface with an external third party business partner. The interface will be imperceptible to the user, though the presentation of information obtained through the interface certainly would not. Second, a constraint limits design alternatives, whereas a requirement specifies design characteristics. To continue the example, a requirement selecting a web service interface is different from a constraint limiting design alternatives to methods compatible with a Single Sign-On architecture.

</p>

<div class="mw-heading mw-heading3"><h3 id="Verification">Verification</h3></div>

<p>All requirements should be verifiable. The most common method is by test. If this is not the case, another verification method should be used instead (e.g. analysis, demonstration, inspection, or review of design).

</p><p>Certain requirements, by their very structure, are not verifiable. These include requirements that say the system must <i>never</i> or <i>always</i> exhibit a particular property. Proper testing of these requirements would require an infinite testing cycle. Such requirements must be rewritten to be verifiable. As stated above all requirements must be verifiable.

</p><p>Non-functional requirements, which are unverifiable at the software level, must still be kept as a documentation of customer intent. However, they may be traced to process requirements that are determined to be a practical way of meeting them. For example, a non-functional requirement to be free from <a href="Backdoor_(computing)" title="Backdoor (computing)">backdoors</a> may be satisfied by replacing it with a process requirement to use <a href="Pair_programming" title="Pair programming">pair programming</a>. Other non-functional requirements will trace to other system components and be verified at that level. For example, system reliability is often verified by analysis at the system level. <a href="Avionics_software" title="Avionics software">Avionics software</a> with its complicated safety requirements must follow the <a href="DO-178B" title="DO-178B">DO-178B</a> development process.

</p><p>Activities that lead to the derivation of the system or software requirements. Requirements engineering may involve a <a href="Feasibility_study" title="Feasibility study">feasibility study</a> or a <i>conceptual analysis phase</i> of the project and <a href="Requirements_elicitation" title="Requirements elicitation">requirements elicitation</a> (gathering, understanding, reviewing, and articulating the needs of the <a href="Stakeholder_(corporate)" title="Stakeholder (corporate)">stakeholders</a>) and <a href="Requirements_analysis" title="Requirements analysis">requirements analysis</a>,<sup id="cite_ref-10" class="reference"><a href="#cite_note-10"><span class="cite-bracket">[</span>10<span class="cite-bracket">]</span></a></sup> <a href="Requirements_analysis" title="Requirements analysis">analysis</a> (checking for consistency and completeness), specification (documenting the requirements) and validation (making sure the specified requirements are correct).<sup id="cite_ref-Wiegers03_11-0" class="reference"><a href="#cite_note-Wiegers03-11"><span class="cite-bracket">[</span>11<span class="cite-bracket">]</span></a></sup><sup id="cite_ref-Young01_12-0" class="reference"><a href="#cite_note-Young01-12"><span class="cite-bracket">[</span>12<span class="cite-bracket">]</span></a></sup>

</p><p>Requirements are prone to issues of ambiguity, incompleteness, and inconsistency. Techniques such as rigorous <a href="Software_inspection" title="Software inspection">inspection</a> have been shown to help deal with these issues. Ambiguities, incompleteness, and inconsistencies that can be resolved in the requirements phase typically cost orders of magnitude less to correct than when these same issues are found in later stages of product development. Requirements analysis strives to address these issues.

</p><p>There is an engineering trade off to consider between requirements which are too vague, and those which are so detailed that they

</p>

<ul><li>take a long time to produce - sometimes to the point of being obsolete once completed</li>

<li>limit the implementation options available</li>

<li>are costly to produce</li></ul>

<p><a href="Agile_software_development" title="Agile software development">Agile approaches</a> evolved as a way of overcoming these problems, by baselining requirements at a high-level, and elaborating detail on a <a href="Just_in_time_(business)" class="mw-redirect" title="Just in time (business)">just-in-time</a> or <i>last responsible moment</i> basis.

</p>

<div class="mw-heading mw-heading2"><h2 id="Documenting_requirements">Documenting requirements</h2></div>

<p>Requirements are usually written as a means for communication between the different stakeholders. This means that the requirements should be easy to understand both for normal users and for developers. One common way to document a requirement is stating what the system must do. Example: 'The contractor must deliver the product no later than xyz date.' Other methods include <a href="Use_cases" class="mw-redirect" title="Use cases">use cases</a> and <a href="User_stories" class="mw-redirect" title="User stories">user stories</a>.

</p>

<div class="mw-heading mw-heading2"><h2 id="Changes_in_requirements">Changes in requirements</h2></div>

<p>Requirements generally change with time. Once defined and approved, requirements should fall under <a href="Change_control" title="Change control">change control</a>. For many projects, requirements are altered before the system is complete. This is partly due to the complexity of computer software and the fact that users don't know what they want before they see it. This characteristic of requirements has led to <a href="Requirements_management" title="Requirements management">requirements management</a> studies and practices.

</p>

<div class="mw-heading mw-heading2"><h2 id="Issues">Issues</h2></div>

<div class="mw-heading mw-heading3"><h3 id="Competing_standards">Competing standards</h3></div>

<p>There are several competing views of what requirements are and how they should be managed and used. Two leading bodies in the industry are the IEEE and the IIBA. Both of these groups have different but similar definitions of what a requirement is.

</p>

<div class="mw-heading mw-heading3"><h3 id="Disputes_regarding_the_necessity_and_effects_of_software_requirements">Disputes regarding the necessity and effects of software requirements</h3></div>

<p>Many projects have succeeded with little or no agreement on requirements.<sup id="cite_ref-13" class="reference"><a href="#cite_note-13"><span class="cite-bracket">[</span>13<span class="cite-bracket">]</span></a></sup> Some evidence furthermore indicates that specifying requirements can decrease <a href="Creativity" title="Creativity">creativity</a> and design performance <sup id="cite_ref-14" class="reference"><a href="#cite_note-14"><span class="cite-bracket">[</span>14<span class="cite-bracket">]</span></a></sup> Requirements hinder creativity and design because designers become overly preoccupied with provided information.<sup id="cite_ref-15" class="reference"><a href="#cite_note-15"><span class="cite-bracket">[</span>15<span class="cite-bracket">]</span></a></sup><sup id="cite_ref-16" class="reference"><a href="#cite_note-16"><span class="cite-bracket">[</span>16<span class="cite-bracket">]</span></a></sup><sup id="cite_ref-17" class="reference"><a href="#cite_note-17"><span class="cite-bracket">[</span>17<span class="cite-bracket">]</span></a></sup> More generally, some research suggests that software requirements are an <a href="Illusion" title="Illusion">illusion</a> created by misrepresenting design decisions as requirements in situations where no real requirements are evident.<sup id="cite_ref-18" class="reference"><a href="#cite_note-18"><span class="cite-bracket">[</span>18<span class="cite-bracket">]</span></a></sup>

</p><p>Meanwhile, most <a href="Agile_software_development" title="Agile software development">agile software development</a> methodologies question the need for rigorously describing software requirements upfront, which they consider a moving target. Instead, <a href="Extreme_programming" title="Extreme programming">extreme programming</a> for example describes requirements informally using <a href="User_story" title="User story">user stories</a> (short summaries fitting on an index card explaining one aspect of what the system should do), and considers it the developer's duty to directly ask the customer for clarification. Agile methodologies attempt to capture requirements in a series of automated <a href="Acceptance_test" class="mw-redirect" title="Acceptance test">acceptance tests</a>.

</p>

<div class="mw-heading mw-heading3"><h3 id="Requirements_creep">Requirements creep</h3></div>

<p><a href="Scope_creep" title="Scope creep">Scope creep</a> may occur from requirements moving over time. In <a href="Requirements_management" title="Requirements management">Requirements management</a> the alteration of requirements is allowed but if not adequately tracked or preceding steps (business goals then user requirements) are not throttled by additional oversight or handled as a cost and potential program failure, then requirements changes are easy and likely to happen. It is easy for requirement changes to occur faster than developers are able to produce work, and the effort to go <i>backwards</i> as a result.

</p>

<div class="mw-heading mw-heading3"><h3 id="Multiple_requirements_taxonomies">Multiple requirements taxonomies</h3></div>

<p>There are multiple taxonomies for requirements depending on which framework one is operating under. (For example, the stated standards of IEEE, vice IIBA or U.S. DoD approaches). Differing language and processes in different venues or casual speech can cause confusion and deviation from desired process.

</p>

<div class="mw-heading mw-heading3"><h3 id="Process_corruptions">Process corruptions</h3></div>

<p>A process being run by humans is subject to human flaws in governance, where convenience or desires or politics may lead to exceptions or outright subversion of the process and deviations from the textbook way the process is supposed to proceed. Examples include:

</p>

<ul><li>Process with no rigor gets no respect - If exceptions or changes are common, such as the organization running it having little independence or power or not being reliable and transparent in records, it may lead to the overall process being ignored.</li>

<li>New players wanting a do-over - e.g., The natural tendency of new people to want to change their predecessor's work to demonstrate their power or claims of value, such as a new CEO wanting to change the previous CEO's planning, including business goals, of something (such as a software solution) already in development, or a newly created office objects to current development of a project because they did not exist when user requirements were crafted, so they begin an effort to backtrack and re-baseline the project.</li>

<li>Coloring outside the lines - e.g., Users wanting more control do not just input things that meet the requirements management definition of "user requirement" or priority level, but insert design details or favored vendor characteristic as user requirements or everything their office says as the highest possible priority.</li>

<li>Showing up late - e.g., Doing little or no effort in requirements elicitation prior to development. This may be due to thinking they will get the same benefit regardless of individual participation, or that there is no point if they can just insert demands at the testing stage and next spin, or the preference to be always right by waiting for post-work critique.</li></ul>

<p>Within the U.S. Department of Defense process, some historical examples of requirements issues are

</p>

<ul><li>the M-2 Bradley issues of casual requirements movement portrayed in <a href="Pentagon_Wars" class="mw-redirect" title="Pentagon Wars">Pentagon Wars</a>;</li>

<li>the F-16 growth from lightweight fighter concept of the <a href="Fighter_mafia" class="mw-redirect" title="Fighter mafia">Fighter mafia</a>, attributed to F-15 program attempting to sabotage competition or individual offices putting in local desires eroding the concept of being lightweight and low cost.</li>

<li>enthusiasm ca. 1998 for 'Net-Ready' led to its mandate as Key Performance Parameter from the Net-Ready office, outside the office defining requirements process and not consistent to that office's previously defined process, their definition of what a KPP was, or that some efforts might not be appropriate or able to define what constituted 'Net-Ready'.</li></ul>

<ul><li><a href="Business_requirements" title="Business requirements">Business requirements</a></li>

<li><a href="Software_requirements" title="Software requirements">Software requirements</a></li>

<li><a href="Requirements_engineering" title="Requirements engineering">Requirements engineering</a></li>

<li><a href="Requirements_analysis" title="Requirements analysis">Requirements analysis</a></li>

<li><a href="Requirements_elicitation" title="Requirements elicitation">Requirements elicitation</a></li>

<li><a href="Requirements_management" title="Requirements management">Requirements management</a></li>

<li><a href="Requirement_prioritization" title="Requirement prioritization">Requirement prioritization</a></li>

<li><a href="Requirements_traceability" title="Requirements traceability">Requirements traceability</a></li>

<li><a href="Specification_(technical_standard)" title="Specification (technical standard)">Specification (technical standard)</a></li>

<li><a href="Shall_and_will#Technical_specifications" title="Shall and will">Shall and will</a> - phrasing</li>

<li><a href="MoSCoW_Method" class="mw-redirect" title="MoSCoW Method">MoSCoW Method</a> - prioritisation technique</li>

<li><a href="User_story" title="User story">User Story</a></li>

<div class="mw-heading mw-heading2"><h2 id="References">References</h2></div>

/* start https://en.wikipedia.org/ */

.mw-parser-output .reflist{margin-bottom:0.5em;list-style-type:decimal}@media screen{.mw-parser-output .reflist{font-size:90%}}.mw-parser-output .reflist .references{font-size:100%;margin-bottom:0;list-style-type:inherit}.mw-parser-output .reflist-columns-2{column-width:30em}.mw-parser-output .reflist-columns-3{column-width:25em}.mw-parser-output .reflist-columns{margin-top:0.3em}.mw-parser-output .reflist-columns ol{margin-top:0}.mw-parser-output .reflist-columns li{page-break-inside:avoid;break-inside:avoid-column}.mw-parser-output .reflist-upper-alpha{list-style-type:upper-alpha}.mw-parser-output .reflist-upper-roman{list-style-type:upper-roman}.mw-parser-output .reflist-lower-alpha{list-style-type:lower-alpha}.mw-parser-output .reflist-lower-greek{list-style-type:lower-greek}.mw-parser-output .reflist-lower-roman{list-style-type:lower-roman}

/* end https://en.wikipedia.org/ */

</style><div class="reflist">

/* start https://en.wikipedia.org/ */

.mw-parser-output cite.citation{font-style:inherit;word-wrap:break-word}.mw-parser-output .citation q{quotes:"\"""\"""'""'"}.mw-parser-output .citation:target{background-color:rgba(0,127,255,0.133)}.mw-parser-output .id-lock-free.id-lock-free a{background:url("./mw/Lock-green.svg")right 0.1em center/9px no-repeat}.mw-parser-output .id-lock-limited.id-lock-limited a,.mw-parser-output .id-lock-registration.id-lock-registration a{background:url("./mw/Lock-gray-alt-2.svg")right 0.1em center/9px no-repeat}.mw-parser-output .id-lock-subscription.id-lock-subscription a{background:url("./mw/Lock-red-alt-2.svg")right 0.1em center/9px no-repeat}.mw-parser-output .cs1-ws-icon a{background:url("./mw/Wikisource-logo.svg")right 0.1em center/12px no-repeat}body:not(.skin-timeless):not(.skin-minerva) .mw-parser-output .id-lock-free a,body:not(.skin-timeless):not(.skin-minerva) .mw-parser-output .id-lock-limited a,body:not(.skin-timeless):not(.skin-minerva) .mw-parser-output .id-lock-registration a,body:not(.skin-timeless):not(.skin-minerva) .mw-parser-output .id-lock-subscription a,body:not(.skin-timeless):not(.skin-minerva) .mw-parser-output .cs1-ws-icon a{background-size:contain;padding:0 1em 0 0}.mw-parser-output .cs1-code{color:inherit;background:inherit;border:none;padding:inherit}.mw-parser-output .cs1-hidden-error{display:none;color:var(--color-error,#d33)}.mw-parser-output .cs1-visible-error{color:var(--color-error,#d33)}.mw-parser-output .cs1-maint{display:none;color:#085;margin-left:0.3em}.mw-parser-output .cs1-kern-left{padding-left:0.2em}.mw-parser-output .cs1-kern-right{padding-right:0.2em}.mw-parser-output .citation .mw-selflink{font-weight:inherit}@media screen{.mw-parser-output .cs1-format{font-size:95%}html.skin-theme-clientpref-night .mw-parser-output .cs1-maint{color:#18911f}}@media screen and (prefers-color-scheme:dark){html.skin-theme-clientpref-os .mw-parser-output .cs1-maint{color:#18911f}}

/* end https://en.wikipedia.org/ */

</style><cite class="citation book cs1"><a rel="nofollow" class="external text" href="http://www.astm.org/COMMIT/Blue_Book.pdf"><i>Form and Style of Standards, ASTM Blue Book</i></a> <span class="cs1-format">(PDF)</span>. <a href="ASTM_International" title="ASTM International">ASTM International</a>. 2012<span class="reference-accessdate">. Retrieved <span class="nowrap">5 January</span> 2013</span>.</cite></span>

</li>

<li id="cite_note-2"><span class="mw-cite-backlink"><b><a href="#cite_ref-2">^</a></b></span> <span class="reference-text"><cite id="CITEREFBoehm2006" class="citation conference cs1">Boehm, Barry (2006). <a rel="nofollow" class="external text" href="http://dl.acm.org/citation.cfm?id=1134288">"A view of 20th and 21st century software engineering"</a>. <i>ICSE '06 Proceedings of the 28th international conference on Software engineering</i>. University of Southern California, University Park Campus, Los Angeles, CA: Association for Computing Machinery, ACM New York, NY, USA. pp. <span class="nowrap">12–</span>29. <a href="ISBN_(identifier)" class="mw-redirect" title="ISBN (identifier)">ISBN</a> <bdi>1-59593-375-1</bdi><span class="reference-accessdate">. Retrieved <span class="nowrap">January 2,</span> 2013</span>.</cite></span>

</li>

<li id="cite_note-3"><span class="mw-cite-backlink"><b><a href="#cite_ref-3">^</a></b></span> <span class="reference-text"><cite class="citation web cs1"><a rel="nofollow" class="external text" href="http://www.iiba.org/babok-guide/babok-guide-v2/babok-guide-online/chapter-one-introduction/1-3-key-concepts.aspx">"1.3 Key Concepts - IIBA | International Institute of Business Analysis"</a>. <i>www.iiba.org</i><span class="reference-accessdate">. Retrieved <span class="nowrap">2016-09-25</span></span>.</cite></span>

</li>

<li id="cite_note-4"><span class="mw-cite-backlink"><b><a href="#cite_ref-4">^</a></b></span> <span class="reference-text"><cite class="citation web cs1"><a rel="nofollow" class="external text" href="https://web.archive.org/web/20110110043912/http://standards.ieee.org/findstds/standard/610.12-1990.html">"IEEE SA - 610.12-1990 - IEEE Standard Glossary of Software Engineering Terminology"</a>. Archived from <a rel="nofollow" class="external text" href="http://standards.ieee.org/findstds/standard/610.12-1990.html">the original</a> on January 10, 2011.</cite></span>

</li>

<li id="cite_note-5"><span class="mw-cite-backlink"><b><a href="#cite_ref-5">^</a></b></span> <span class="reference-text"><cite id="CITEREFIibaAnalysis2009" class="citation book cs1">Iiba; Analysis, International Institute of Business (2009). <a rel="nofollow" class="external text" href="http://IIBA.org"><i>A Guide to the Business Analysis Body of Knowledge® (BABOK® Guide) Version 2.0</i></a>. <a href="ISBN_(identifier)" class="mw-redirect" title="ISBN (identifier)">ISBN</a> <bdi>978-0-9811292-1-1</bdi>.</cite> <span class="cs1-visible-error citation-comment"><code class="cs1-code">{{cite book}}</code>: </span><span class="cs1-visible-error citation-comment"><code class="cs1-code">|first2=</code> has generic name (help)</span></span>

</li>

<li id="cite_note-ASR_Chen-6"><span class="mw-cite-backlink"><b><a href="#cite_ref-ASR_Chen_6-0">^</a></b></span> <span class="reference-text"><cite id="CITEREFChenAli_BabarNuseibeh2013" class="citation journal cs1">Chen, Lianping; Ali Babar, Muhammad; Nuseibeh, Bashar (2013). "Characterizing Architecturally Significant Requirements". <i>IEEE Software</i>. <b>30</b> (2): <span class="nowrap">38–</span>45. <a href="Doi_(identifier)" class="mw-redirect" title="Doi (identifier)">doi</a>:<a rel="nofollow" class="external text" href="https://doi.org/10.1109%2FMS.2012.174">10.1109/MS.2012.174</a>. <a href="Hdl_(identifier)" class="mw-redirect" title="Hdl (identifier)">hdl</a>:<span class="id-lock-free" title="Freely accessible"><a rel="nofollow" class="external text" href="https://hdl.handle.net/10344%2F3061">10344/3061</a></span>. <a href="S2CID_(identifier)" class="mw-redirect" title="S2CID (identifier)">S2CID</a> <a rel="nofollow" class="external text" href="https://api.semanticscholar.org/CorpusID:17399565">17399565</a>.</cite></span>

</li>

<li id="cite_note-7"><span class="mw-cite-backlink"><b><a href="#cite_ref-7">^</a></b></span> <span class="reference-text">Ralph, P., and Wand, Y. A Proposal for a Formal Definition of the Design Concept. In, Lyytinen, K., Loucopoulos, P., <a href="John_Mylopoulos" title="John Mylopoulos">Mylopoulos, J.</a>, and Robinson, W., (eds.), Design Requirements Engineering: A Ten-Year Perspective: Springer-Verlag, 2009, pp. 103-136</span>

</li>

<li id="cite_note-Davis93-8"><span class="mw-cite-backlink"><b><a href="#cite_ref-Davis93_8-0">^</a></b></span> <span class="reference-text"><cite id="CITEREFDavis1993" class="citation book cs1">Davis, Alan M. (1993). <a rel="nofollow" class="external text" href="https://archive.org/details/softwarerequirem0000davi"><i>Software Requirements: Objects, Functions, and States, Second Edition</i></a>. Prentice Hall. <a href="ISBN_(identifier)" class="mw-redirect" title="ISBN (identifier)">ISBN</a> <bdi>978-0-13-805763-3</bdi>.</cite></span>

</li>

<li id="cite_note-IEEE_830-1998_standard-9"><span class="mw-cite-backlink"><b><a href="#cite_ref-IEEE_830-1998_standard_9-0">^</a></b></span> <span class="reference-text"><cite id="CITEREFIEEE_Computer_Society1998" class="citation book cs1">IEEE Computer Society (1998). <i>IEEE Recommended Practice for Software Requirements Specifications</i>. Institute of Electrical and Electronics Engineers, Inc. <a href="ISBN_(identifier)" class="mw-redirect" title="ISBN (identifier)">ISBN</a> <bdi>978-0-7381-0332-7</bdi>.</cite></span>

</li>

<li id="cite_note-10"><span class="mw-cite-backlink"><b><a href="#cite_ref-10">^</a></b></span> <span class="reference-text"><cite id="CITEREFStellmanGreene2005" class="citation book cs1">Stellman, Andrew; Greene, Jennifer (2005). <a rel="nofollow" class="external text" href="https://web.archive.org/web/20150209011617/http://www.stellman-greene.com/aspm/"><i>Applied Software Project Management</i></a>. O'Reilly Media. p. 98. <a href="ISBN_(identifier)" class="mw-redirect" title="ISBN (identifier)">ISBN</a> <bdi>978-0-596-00948-9</bdi>. Archived from <a rel="nofollow" class="external text" href="http://www.stellman-greene.com/aspm/">the original</a> on 2015-02-09.</cite></span>

</li>

<li id="cite_note-Wiegers03-11"><span class="mw-cite-backlink"><b><a href="#cite_ref-Wiegers03_11-0">^</a></b></span> <span class="reference-text"><cite id="CITEREFWiegers2003" class="citation book cs1">Wiegers, Karl E. (2003). <i>Software Requirements, Second Edition</i>. Microsoft Press. <a href="ISBN_(identifier)" class="mw-redirect" title="ISBN (identifier)">ISBN</a> <bdi>978-0-7356-1879-4</bdi>.</cite></span>

</li>

<li id="cite_note-Young01-12"><span class="mw-cite-backlink"><b><a href="#cite_ref-Young01_12-0">^</a></b></span> <span class="reference-text"><cite id="CITEREFYoung2001" class="citation book cs1">Young, Ralph R. (2001). <a rel="nofollow" class="external text" href="https://archive.org/details/unset0000unse_g5k2"><i>Effective Requirements Practices</i></a>. Addison-Wesley. <a href="ISBN_(identifier)" class="mw-redirect" title="ISBN (identifier)">ISBN</a> <bdi>978-0-201-70912-4</bdi>.</cite></span>

</li>

<li id="cite_note-13"><span class="mw-cite-backlink"><b><a href="#cite_ref-13">^</a></b></span> <span class="reference-text"><cite id="CITEREFCheckland1999" class="citation book cs1">Checkland, Peter (1999). <i>System Thinking, System Practice</i>. Chichester: Wiley.</cite></span>

</li>

<cite id="CITEREFRalphMohanani2015" class="citation conference cs1">Ralph, Paul; Mohanani, Rahul (May 2015). <a rel="nofollow" class="external text" href="https://www.researchgate.net/publication/272793687">"Is Requirements Engineering Inherently Counterproductive?"</a>. <i>Proceedings of the 5th International Workshop on the Twin Peaks of Requirements and Architecture</i>. Florence, Italy: IEEE. pp. <span class="nowrap">20–</span>23.</cite></span>

</li>

<li id="cite_note-15"><span class="mw-cite-backlink"><b><a href="#cite_ref-15">^</a></b></span> <span class="reference-text"><cite id="CITEREFJanssonSmith1991" class="citation journal cs1">Jansson, D.; Smith, S. (1991). "Design fixation". <i>Design Studies</i>. <b>12</b> (1): <span class="nowrap">3–</span>11. <a href="Doi_(identifier)" class="mw-redirect" title="Doi (identifier)">doi</a>:<a rel="nofollow" class="external text" href="https://doi.org/10.1016%2F0142-694X%2891%2990003-F">10.1016/0142-694X(91)90003-F</a>.</cite></span>

</li>

<li id="cite_note-16"><span class="mw-cite-backlink"><b><a href="#cite_ref-16">^</a></b></span> <span class="reference-text"><cite id="CITEREFPurcellGero1996" class="citation journal cs1">Purcell, A.; Gero, J. (1996). "Design and other types of fixation". <i>Design Studies</i>. <b>17</b> (4): <span class="nowrap">363–</span>383. <a href="Doi_(identifier)" class="mw-redirect" title="Doi (identifier)">doi</a>:<a rel="nofollow" class="external text" href="https://doi.org/10.1016%2FS0142-694X%2896%2900023-3">10.1016/S0142-694X(96)00023-3</a>.</cite></span>

</li>

<cite id="CITEREFMohananiRalphShreeve2014" class="citation conference cs1">Mohanani, Rahul; Ralph, Paul; Shreeve, Ben (May 2014). <a rel="nofollow" class="external text" href="https://www.researchgate.net/publication/265416695">"Requirements Fixation"</a>. <i>Proceedings of the International Conference on Software Engineering</i>. Hyderabad, India: IEEE. pp. <span class="nowrap">895–</span>906.</cite></span>

</li>

<li id="cite_note-18"><span class="mw-cite-backlink"><b><a href="#cite_ref-18">^</a></b></span> <span class="reference-text"><cite id="CITEREFRalph2012" class="citation journal cs1">Ralph, Paul (2012). "The Illusion of Requirements in Software Development". <i>Requirements Engineering</i>. <b>18</b> (3): <span class="nowrap">293–</span>296. <a href="ArXiv_(identifier)" class="mw-redirect" title="ArXiv (identifier)">arXiv</a>:<span class="id-lock-free" title="Freely accessible"><a rel="nofollow" class="external text" href="https://arxiv.org/abs/1304.0116">1304.0116</a></span>. <a href="Doi_(identifier)" class="mw-redirect" title="Doi (identifier)">doi</a>:<a rel="nofollow" class="external text" href="https://doi.org/10.1007%2Fs00766-012-0161-4">10.1007/s00766-012-0161-4</a>. <a href="S2CID_(identifier)" class="mw-redirect" title="S2CID (identifier)">S2CID</a> <a rel="nofollow" class="external text" href="https://api.semanticscholar.org/CorpusID:11499083">11499083</a>.</cite></span>

</li>

</ol></div></div>

<div class="mw-heading mw-heading2"><h2 id="External_links">External links</h2></div>

/* start https://en.wikipedia.org/ */

.mw-parser-output .side-box{margin:4px 0;box-sizing:border-box;border:1px solid #aaa;font-size:88%;line-height:1.25em;background-color:var(--background-color-interactive-subtle,#f8f9fa);display:flow-root}.mw-parser-output .infobox .side-box{font-size:100%}.mw-parser-output .side-box-abovebelow,.mw-parser-output .side-box-text{padding:0.25em 0.9em}.mw-parser-output .side-box-image{padding:2px 0 2px 0.9em;text-align:center}.mw-parser-output .side-box-imageright{padding:2px 0.9em 2px 0;text-align:center}@media(min-width:500px){.mw-parser-output .side-box-flex{display:flex;align-items:center}.mw-parser-output .side-box-text{flex:1;min-width:0}}@media(min-width:720px){.mw-parser-output .side-box{width:238px}.mw-parser-output .side-box-right{clear:right;float:right;margin-left:1em}.mw-parser-output .side-box-left{margin-right:1em}}

/* end https://en.wikipedia.org/ */

</style><style data-mw-deduplicate="TemplateStyles:r1237033735">

/* start https://en.wikipedia.org/ */

@media print{body.ns-0 .mw-parser-output .sistersitebox{display:none!important}}@media screen{html.skin-theme-clientpref-night .mw-parser-output .sistersitebox img[src*="Wiktionary-logo-en-v2.svg"]{background-color:white}}@media screen and (prefers-color-scheme:dark){html.skin-theme-clientpref-os .mw-parser-output .sistersitebox img[src*="Wiktionary-logo-en-v2.svg"]{background-color:white}}

/* end https://en.wikipedia.org/ */

</style><div class="side-box side-box-right sistersitebox"><style data-mw-deduplicate="TemplateStyles:r1126788409">

/* start https://en.wikipedia.org/ */

.mw-parser-output .plainlist ol,.mw-parser-output .plainlist ul{line-height:inherit;list-style:none;margin:0;padding:0}.mw-parser-output .plainlist ol li,.mw-parser-output .plainlist ul li{margin-bottom:0}

/* end https://en.wikipedia.org/ */

</style>

<div class="side-box-text plainlist">Look up <i><b><a href="https://en.wiktionary.org/wiki/Special:Search/requirement" class="extiw external" title="wiktionary:Special:Search/requirement">requirement</a></b></i> in Wiktionary, the free dictionary.</div></div>

</div>

<ul><li><a rel="nofollow" class="external text" href="http://prod.sandia.gov/techlib/access-control.cgi/1996/961620.pdf"><i>Discovering System Requirements</i></a></li></ul></div><div><div class="zim-footer">

This article is issued from <a class="external text" title="Last edited on 2025-06-27" href="https://en.wikipedia.org/wiki/?title=Requirement&oldid=1297636765">Wikipedia</a>. The text is available under <a class="external text" href="https://creativecommons.org/licenses/by-sa/4.0/deed.en">Creative Commons Attribution-Share Alike 4.0</a> unless otherwise noted. Additional terms may apply for the media files.

</div>

</div></div>

</div>

</main>

</div>

</body></html>